Rename the implicit result variable along with its function - #538

Fixes #322

The bug

A Fortran function declared without a RESULT() clause returns through an
implicit result variable that shares the function's name:

real pure function sind(x)
    real, intent(in), value :: x
    sind = sin(x*((4.0*atan(1.0))/180.0))   ! <- implicit result variable
end function

Renaming sind renamed only the declaration and left the assignment alone,
producing code that no longer compiles.

Root cause

fortls models the implicit result variable as a distinct object with its own
FQSN. For the function above:

get_all_references matches candidates with def_fqsn == var_def.FQSN
(langserver.py:994), so the body occurrence never matched and was dropped.

Two things worth noting, since the issue speculated about both:

• This is not the intrinsic collision. A plain user function named
  myfunc fails identically, so sind shadowing the intrinsic is not
  involved. After this change the original sind case renames correctly and
  the sin/atan calls on the same line are still left alone.
• Functions with an explicit RESULT() clause were never affected —
  there both sites resolve to the same Variable, so they already matched.

textDocument/definition already resolved the body occurrence to the
function, so rename and definition disagreed with each other.

The fix

Link the function and its implicit result variable through the existing
override_cache, in both directions, so a rename started from the
declaration or from the body updates both sites. The link is only made when
result_name == name, i.e. when the result variable really is implicit;
explicit RESULT() clauses take the existing path untouched.

textDocument/references and documentHighlight share this code path and are
fixed by the same change:

before:  myfunc.f90 (3, 24)
after:   myfunc.f90 (3, 24)
         myfunc.f90 (5, 9)

Tests

Three tests plus a new fixture, test_rename_implicit_result.f90:

• test_rename_implicit_function_result — rename from the declaration
• test_rename_implicit_function_result_from_body — rename from the body
• test_rename_explicit_function_result — explicit RESULT() unchanged

The first two fail on master and pass here; the third passes either way and
guards against a regression.

They assert the number of changes explicitly, because
check_rename_response zips changes against expectations and would otherwise
silently pass when a change is missing — which is exactly the failure mode
here.

Full suite: 184 passed. pre-commit clean.